I was thinking about keeping acquire_gil around for a while longer, because I think a lot of people still use it, and maybe use it in ways that aren't trivial to rewrite using with_gil. That said I also don't like having both around, so +1 to this.

I think this would be worth it considering how much tricky/unsafe code can be removed or get reduced visibility due to this, especially the drop order checking which could inject unexpected and intermittent panics into downstream code.

I think what I'll do is add a migration guide entry for removal of Python::acquire_gil, so that it's easier for users to understand what happened and how to change it.

@davidhewitt I would like to help here if I can as I would very much like to see this merged for the reduction in complexity it allows. Would you mind if I tried to rebase this and add another commit for the migration guide entry?

Please do, at the moment when I get a scrap of time I'm trying to finish off #3029

I added an entry to the migration guide but admittedly the example is quite artificial. Please have a look and let me know if this is sufficient for our purposes.

bors r=adamreichold,davidhewitt

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

• conclusion